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NAVIGATING NETWORK RESOURCES 
BASED ON METADATA 

FIELD OF THE INVENTION 

The present invention generally relates to data processing, 
and relates specifically to methods and computer systems for 
managing names of network resources and locating the 
resources. 

BACKGROUND OF THE INVENTION 

Recently, a global packet-switched network known as the 
Internet has attracted wide use. A local computer can con- 
nect to a distant server, request a file or an image from the 
server, and receive the requested information immediately. 

The Internet operates according to several standard pro- 
tocols. For example, packets of data are communicated 
among Internet host computers ("servers") using the Trans- 
mission Control Protocol (TCP) and Internet Protocol (IP). 

Each server that is accessible using the Internet or con- 
nected to the Internet is associated with a unique numeric 
identifier called an IP address. Each IP address has four 
numeric parts, and each part has a value in the range 0 to 
255. An example IP address is "204.93.112.93". The IP 
addresses are assigned and managed by a central Internet 
Assigned Names Authority. Numeric identifiers are rapidly 
and conveniently processed by computers, but are inconve- 
nient for humans to remember and type. 

Accordingly, in 1984 the Domain Name System (DNS) 
was introduced. DNS is a distributed information database 
that maps the IP address of a server to a host name or 
"domain name". For example, the domain name www.cen- 
traal.com is mapped to the IP address 209.76.1533 in the 
DNS system. The database is available at several computer 
systems around the world known as DNS servers. A local 
computer can look up a remote server by connecting to a 
DNS server, providing a domain name to the DNS server, 
and obtaining the IP address that corresponds to the domain 
name. The local computer can then connect to the remote 
computer using the IP address, and send and receive infor- 
mation. 

Generally domain names comprise two or more alphanu- 
meric fields, separated by periods. The right-most field is the 
generic top-level domain (gTLD) name. The "com" portion 
of the domain name "centraal.com" is a generic top-level 
domain name that indicates that "centraal.com" is a com- 
mercial domain. Other gTLD's include "mil" (for military 
domains), "gov" (for government domains), and "edu" (for 
domains of educational institutions). Still other gTLDs have 
been proposed for creation. 

The "centraal" portion ofccntraal.com" is a second level 
domain name or organization name. Usually the second 
level domain name is also the name of a specific network 
server or host at the institution that owns the domain name. 
Domain names also can have third-level domain names, 
such as "www", that identify a sub-domain of the 
organization, such as a sub-directory of the network server, 
or a specific computer or workstation. 

Domain names may also incorporate geographic portions. 
An example is the domain name "rcsd.rcdwood-city.ca.us". 
The "us" portion indicates the United States; the "ca" 
portion refers to the State of California; "redwood-city" is 
the organization name; and "rcsd" is the sub-domain. In 
some nations, such as the United Kingdom, the order of 
these elements is reversed. 

One popular technology enjoying wide use with the 
Internet is known as the World Wide Web. The World Wide 
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Web enables a computer to locate a remote server using the 
DNS and then establish a connection to the server and 
retrieve information using a communication protocol called 
the Hypertext Transfer Protocol (HTTP). Each item of 

5 information available using the Web, including files, images, 
or pages, is called a resource. A Uniform Resource Locator 
(URL) uniquely identifies each resource stored on a server. 
A URL is a form of network address comprising a domain 
name coupled to an identifier of the location of information 

to stored in a network. 

An example of a URL is http://www.centraal.com/ 
index-html. In this example, "http://" indicates that the 
information associated with the URL can be accessed using 
HTTP; www.centraal.com identifies the server that is storing 

15 the information; and "index.html" identifies a file or page on 
that server. 

The local computer requests information by providing a 
request containing a URL of the desired information to the 
remote server. The server receives the request, locates the 

20 page of information corresponding to the URL, and returns 
the page to the local computer over the HTTP connection. 
The pages of information are files prepared in the Hypertext 
Markup Language (HTML). The local computer runs a 
browser program that can read HTML files, interpret HTML 

25 codes in the files, and generate a complex graphical display. 
Because the Web offers so much information about so 
many subjects, often the Web is compared to a library. In this 
analogy, the books in the library are network resources such 

3Q as Web pages. All of the books are written in the same 
language, namely HTML. Unfortunately, although HTML is 
a simple language, it does not provide a mechanism that can 
be used to express attributes relating to a network resource. 
Thus, continuing the library analogy, a Web page is like a 

35 book that has no cover. The content of the Web page can be 
read, but there is no descriptive information about the Web 
page, such as its title, subject, or publication date, associated 
with the Web page. It is dtfficult to identify or refer to a book 
that has no title. Since Web pages do not inherently contain 

^ a cover that stores a title, conventionally, Web pages are 
referenced by a location identifier or URL in the DNS 
system. The current DNS system as implemented with the 
Web has several disadvantages and drawbacks. Although the 
DNS system ensures that each URL is unique across the 

45 Web, URLs are difficult to remember and associate with a 
particular institution, person, or product related to the owner 
of the domain or page associated with the URL. For 
example, to locate a page of information about the Walt 
Disney film "Bambi", in the current system a user must enter 

5Q a complex URL into the browser, such as http:// 
www.disney.com/DisncyVidcos/masterpicce/shelves/ 
bambi. 

Thus, an inherent disadvantage of the DNS system is that 
the user must know the exact location and name of the 

55 desired information. In the library analogy, URLs are like 
card catalog numbers. Few persons go to a library knowing 
the exact card catalog number of a desired book. However, 
in the Web environment, there is no alternative, even though 
users tend to naturally remember the names of network 

go resources but not their locations. Moreover, network 
resources are volatile; their locations may change or be 
reorganized over time at the discretion of the operator of the 
server that stores the network resource. Thus, a URL that is 
accurate one day might be inaccurate the next day, so that the 

65 network resource cannot be located. 

Further, the network address must be typed correctly 
every time or the resource will not be found. The format of 
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URLs is complex and unpredictable. Errors are bard to spot. Based upon the foregoing, it is clearly desirable to provide 

Addresses are difficult to guess. a way to associate abstract properties of a network resource 

A further disadvantage of the DNS system is that accord- with the network resource, 

ing to current standard protocols, network addresses or 1 1 is also desirable to have a way to access information 

URLs can be expressed in only 60 alphabetic and symbolic 5 available over the Web using a natural language word or 

characters. The alphabetic characters can be expressed only „ rcal „ ^ ^ thc m f onnatlon . 
m the Roman alphabet using the letters A through Z and the 

digits "0" through "9". This limited character set imposes a H * also desirable to have a Web browser program that 

severe limitation on the use of DNS in international com- can ra P ldl y locatc > loatL ^ information in response 

munications. For example, it is not currently possible to 1Q to receiving a natural language word or "real" name asso- 
express a network address or URL in the Cyrillic characters. ciated with the information, thereby providing a way to 

used in the Russian language or in the Kanji characters used instantly retrieve information stored in a network based 

in the Japanese language; upon the real name rather than the address of the informa- 

Because of the difficulty of associating a location identi- non - 

fier with a desired network resource, specialized Web sites ^ It is also desirable to have such a system that can 

known as " search engines" have been developed to provide automatically and immediately navigate or direct the user to 

a way to enter natural language words or phrases and a particular network resource, without providing or requir- 

retrieve a list of other Web sites that contain the words or mg the ^ to through a list of results or matches. It 

phrases. Examples of search engines are AltaVista, Yahoo!, ^ also desirable to have a flexible, simple way to associate 

and Lycos. However, search engine technology has hrnita- a natural langua word or « rear name ^ a xt of 

Lions and drawbacks, tor example, search engines do not 20 m f orma ii on 
understand the content of the Web pages indexed by the 

search engine; search engines merely remember the Web It is also desirable to have such a system that can associate 

pages, a natural language word or name with a subordinate page of 

Further, search engines merely return a list of Web pages a Wcb site rather man with onl y toe "home" or root page, 

that contain the words or phrases entered by the user, they 25 It is also desirable to have such a system that can associate 

do not automatically navigate to a pertinent page. The list a natural language word or name only with an organization 

returned by the search engine may have thousands of entries, that owns, operates, or produces a product, service, or other 

many of which are irrelevant to what the user wants. In the thing that is identified by the word or name, 

library analogy, this process is like requesting a hbrarian to uLsalso desirable to have a way to associate information 

search for a book, and receiving fromthe librarian a list of 30 slored m a network with human-readable resource names, so 

card catalog numbers at which the book might be located. ^ end uscrs ^ me nctwork ^ ^ mplc words 

In addition, the list almost always contains entries that and exprC ssed in any human written language, 

merely mention the words or phrases entered by the user but fi . , . . , . ... 

. , , . . c , v. It is also desirable to have a way to associate multiple 

are not associated with the owner of a product or service . . . ' t , ,T, 

■j 4-c j u , L _ . , r . names, each expressed in a different human-readable 

identified by those words or phrases, ror example, a user 35 . . , , . . 

... /. . . « 7 . t . , . . . language, with the same network resource, so that a par- 
might want to locate the Web site owned and operated by . , * , , . . . 

. .... ~, . . . - *_„ . . ,l ticular network resource can be retrieved in a language- 
United Airlines. The user enters "United Airlines into the ... , 6 & 

cue , . .„ , _ independent manner, 

query field of a search engine. I ne search engine returns a r 

list of Wcb sites or Web pages that contain the words "United It is also desirable to have such a system configured in a 

Airlines." However, many of the entries in the list are not 40 wa y iha \ P rovldcs distributed storage of the real name 

owned or operated by United Airlines; they arc owned or information. 

operated by third parties that merely mention the words in There is a further need for a mechanism to navigate to a 

their pages. Further, the lists produced by search engines network resource based upon its name and without misdi- 

ofien are unordered, so that the user must carefully search rection caused by a metatag in the network resource. 

the list to identify a desired entry. While search engine 45 ciiumadv ru? wc iwx/cwnnw 
, . , . , j , 4. ,l nrt SUMMARY Or 1 tie, INVENTION 
technology may have been adequate when the Web con- 
tained only a few documents, the Web is currently estimated The foregoing needs, and other needs and objects, arc 
to contain more than 200 million pages, rendering imprac- fulfilled by the present invention, which comprises, in one 
tical the continued use of search engines based on location aspect, a method of navigating, based upon a natural Ian- 
identifiers. Some have proposed making search engines 50 guage name, to a resource that is stored in a network and 
smarter, using new ranking algorithms, semantic analysis, identified by a location identifier, comprising the steps of 
and HTML filtering techniques. Nevertheless, search engine storing a first natural language name of the resource in 
performance continues to degrade because the Web is grow- association with the location identifier of the resource; 
ing faster than search engine technology is improving. receiving a request to locate the resource containing the first 
Search engines also suffer from the disadvantage that they 55 natural language name; retrieving the location identifier 
can be fooled by metatags. The HTML language defines a associated with the first natural language name; and deliv- 
metatag facility whereby text such as key words or descrip- ering the resource to the user using the location identifier, 
tions is written into a Web page's HTML code as a means One feature of this aspect involves storing at least a 
for a search engine to categorize the content of the Web second natural language name for the resource, expressed in 
page. The browser does not display the metatags when the 60 a language other than that of the first natural language name, 
Web page is received and decoded at the client The metatag in association with the location identifier; receiving requests 
facility can be used to fool a search engine by encoding a to locate the resource based on the first and second natural 
non-displayed keyword into a Web page that has nothing to language names; retrieving the location identifier associated 
do with the actual content of thc page. When the keyword is with the first and second natural language names; and 
used for a Web search, the Web page is located and displayed 65 retrieving and displaying the resource using the location 
even though the displayed content of the page is unrelated to identifier. Another feature involves the steps of storing the 
the key word. first and second natural language names in association with 
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the location identifier, and in a name file in a storage device ing description, for the purposes of explanation, numerous 

associated with the resource. specific details are set forth in order to provide a thorough 

Yet another feature involves the steps of retrieving the understanding of the present invention. It will be apparent, 

name file; parsing the name file; building an index entry however, to one skilled in the art that the present invention 

based on the values parsed from the name file; and storing 5 may be practiced without these specific details. In other 

the index entry in an index that is stored apart from the instances, well-known structures and devices are shown in 

storage device. Still another feature is the steps of sending block diagram form in order to avoid unnecessarily obscur- 

the name file over the network to a client associated with the m g ^ present invention, 
resource; and storing the name file in a server storage device 

of a server associated with the client. Another feature 1Q Name File Format 
involves periodically polling the name file on the server 

associated with the client; testing whether one of the natural In ^ preferred embodiment, metadata is associated with 

language names stored in the name file matches a third network resources such as Web pages. Generally, metadata 

natural language name stored in a database indexed by the is data that describes other data. The metadata defined herein 

index; and updating the database when changes are detected provides information that describes a Web page in a manner 

in the name file. Yet another feature is the step of synchro- 15 analogous to the manner by which a catalog card describes 

nizing the index to the database. a book in a library- For example, the metadata includes 

According to another feature, the method includes the information that provides a title (also called a real name 

steps of receiving a client identifier of a client associated address), a description, a language designation, or a geo- 

with the resource; generating a set of metadata that describes graphical location. The metadata is defined by an adrriinis- 

the resource, the location identifier, and the client identifier, 20 trator of the server that stores the Web pages that are 

and storing the set of metadata in a persistent storage device described in the metadata, and a copy of the metadata is 

associated with the client. Another feature is assigning a stored in association with that server so that the metadata is 

randomly generated name to the set of metadata. Yet another accessible using tbe Web. Using a Librarian, the a copy of 

feature is instructing the client to store the metadata in a the metadata is registered with a database that is coupled to 

particular authorized location in the persistent storage 25 ^ m d ex . 

device. Another feature is registering the set of metadata and Preferably, the metadata is prepared and initially stored in 

the randomly generated name in a database. mc f orm of a Name File 64 is a text file defined by the 

The foregoing is merely a brief summary of one aspect of Extensible Markup Language (XML) grammar. XML is a 

the invention. The invention encompasses many other language definition promoted by Microsoft Corporation and 

aspects, as set forth in the appended claims. 30 Netscape Communications Corporation. Further informa- 

BRIEF DESCRIPTION OF THE DRAWINGS uon about XML » provided in "XML; Principles, Tools, and 

r „ ...... , . , , Techniques," The World Wide Web Journal, vol. 2, no. 4 

The present invention is illustrated by way of example, ^ l9QJ) (Scbasl , CaIif , G , Reill & ^ 

and not by way of limitation, in the figures of the accom- ' . 

parking drawings and m which like reference numerals refer 35 <h ^ erably ' ^ * m ^^T^^^^nr, 

to similar elements and in which: ^ Kesou^^finUion Format (-RDF?! Format. RDF is a 

„_„ . . . ,. r C1 syntax of XML designed by the World Wide Web Consor- 

RG. 1A is a diagram of a name file. ^ for expressing semantics. The text file is also called an 

FIG. IB is a block diagram of one embodiment of a RNS ^ ^ exam le of an RNS file is set forth in FIG. 1A. 

system for navigating network resources based on metadata. — , _ vt „ . . _ . ... 

J . „..„.. „ . , r -An The RNS file 900 is defined according to a grammar m 

FIG. 2A .s a flow diagram of a method of a registration « which informalion clemcnls ^ s^^ded by complemcn- 

service in the system of FIG. IB. tary lags , For example, " resource >" and "</resource>" arc 

FIG. 2B is a flow diagram of a method of activating a complementary tags. The RNS file 900 has two general 

name file in the system of FIG. IB. partSj name i y a schema section 902, and a data section 904. 

FIG. 3 is a flow diagram of a method of operating a 45 n, e schema section 902 and the data section 904 are 

crawler in the system of FIG. IB. enclosed within complementary tags ("<xml>, </xml>") that 

FIG. 4 is a block diagram of an index builder service of indicate that the RNS file 900 is in the XML grammar, 

the system of FIG. IB. ^ schema section 902 is delineated by the <schema> 

FIG. 5 is a flow diagram of a method of operating a and </schema> tags. The schema section identifies the 

resolver service in the system of FIG. IB. 5Q schema that is used to organize data in the data section. In 

FIG. 6 is a flow diagram of a method of operating a name the example of FIG. LA, an "href" anchor code in the 

finding service in the system of FIG. IB. schema section refers to a file, "RNS-schema", located on a 

FIG. 7 A is a diagram of an exemplary statistics report Web server, that contains the schema definition. The schema 

page generated by the system of FIG. IB. is assigned the name "RNS." Tags in the RNS file 900 that 

FIG. 7B is a diagram of another exemplary statistics 55 arc part of the RNS schema have a prefix of RNS:". Based 

report page generated by the system of FIG. IB. on this prefix, the XML parser that reads the RNS file 900 

FIG. 8 is a block diagram of a computer system that can can identify tags that are part of the RNS schema, 

be used to implement the present invention. The data section 904 is delineated by the <xml:data> and 

FIG. 9 is a simplified block diagram of a resolution and </xml:data> tags. The data section contains one or more 

navigating system. 60 RNS entries 905. Each RNS entry 905 is delineated by the 

FIG. 10 is a block diagram of a user interface display <assertions> and </assertions>. Conceptually, each 

generated by a navigating service. RNS enu 7 90S is a set of assertions about a network 

resource that is identified within tbe <assertions> tag. In the 

DETAILED DESCRIPTION OF THE example of FIG. 1A, one RNS entry 905 makes assertions 

PREFERRED EMBODIMENT w aboul me network resource home.acme.com, which for 

A mechanism for naming and locating network resources exemplary purposes is the home page of a fictional company, 

in a language-independent way is described. In the follow- Acme Corporation. 
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The RDF language provides a general mechanism for 
describing many types of resources. RDF does not inher- 
ently provide facilities for describing Web pages. 
Accordingly, a Name File 64 is expressed in an RDF 
vocabulary that is specific to Web pages that expresses the 
main attributes of a Web page. The attributes include, for 
example, a real name address, a location identifier or URL, 
a description, a language attribute, a region attribute, and a 
listings attribute. 

Each RNS entry 905 has a set of metadata 906. Id the 
example of FIG. LA, the metadata 906 contains a value that 
identifies the real name of the resource. The real name value, 
"Acme," is between the <realname> and <realname> tags. 
The metadata 906 also includes a description value, a 
language identifier value, and a region identifier value. A 
pair of tags delineates each value. For example, in FIG. 1A, 
the description value is "Home Page of Acme Corporation," 
the language value is "English," and the region value is 
"Global." The description value provides a description of the 
network resource that is associated with the real name: 

When multiple resources are defined in one RNS file, for 
security reasons, each network address declared for a 
resource must be related to the shortest network address that 
is declared in the RNS file for any resource. In the preferred 



to indicate that it is a manufacturer of anvils, rockets, and 
slingshots. 

As another example, United Airlines constructs its Name 
File 64 so as to store the subject property "airlines" in 
5 association with a resource definition. United Van Lines, a 
moving and storage company, stores the subject property 
"moving". When displaying a set of list entries, the system 
displays the subject property value in association with each 
resource. When the user is providing a real name to one of 
10 the services 42-46, the user includes a value for the subject 
property in the query. The system searches for resources in 
the index that match both the real name and the subject 
property value. 

In an alternative embodiment, the resources described in 
is the Name File 64 are persons rather than Web pages. A 
resource of type "person" has metadata including a mailing 
address, email address, and other personal information. In 
this embodiment, the system can be used as a person locator 
service rather than for navigating to Web pages or other 
20 network resources. 

In other alternative embodiments, the Name File 64 stores 
other attributes. For example, other attributes include 
Organization, Subject, Abstract, Type, Audience, and other 
attributes.! In the Organization attribute the Name File 64 



embodiment, each network address must be logically sub- 25 information that identifies an organization or company that 

owns or is associated with the network resource, for 
example, "Federated Stores Incorporated." In the Subject 



ordinate to or descended from the network address in the 
RNS file that is shortest in characters. For example, in the 
excerpt provided in FIG. 1A, all subsequent resource dec- 
larations would be required to identify network addresses 
that specify files located within the directory tree'for which 
www.centraal.com is the root node. This relationship is 
checked by the Registration Service 22 when the RNS file is 
initially created. 

A key advantage of this mechanism is that it can be used 
to provide multilingual access to network resources. One or 
more Name Files 64 are established. The Name Files 64 
store a plurality of entries. Each of the entries stores the 
name of a network resource, in a different language, in 
association with the <realname> field. However, each of the 
entries references the same network resource in association 
with the <resource> tag. 

For example, one or more Name Files 64 have entries that 
store real names in English, French, German, and Japanese. 
Each entry identifies the same network resource. 
Accordingly, the entries establish real names in a plurality of 
different languages, all of which point to or resolve to the 
same network address. When a third party wishes to access 
the referenced network resource, the third party enters the 
real name of the network resource into the browser 74 or the 
GO service 42 in whatever language is most convenient for 
the third party. The Resolver 40 will resolve the real name, 
regardless of language, to the same network address and 
direct the browser to that address. Accordingly, a user can 
locate and access network resources in a language- 
independent manner. 

In an alternative embodiment, the attributes also include 
a listings attribute set off by the tag <RNS:listings>. A 
listings attribute is one or more keywords or other values 
that describe other properties of a resource. For example, 
each resource has a subject property that identifies the 
general nature of the product, service, or organization that is 
associated with the resource. This enables the database to be 
organized like a " yellow pages" directory. As an example, 
Acme Corporation includes in its Name File 64 the line 

<RNS:Iisting9>Anv3s, Rockets, Slingshots 



attribute the Name File 64 stores information that describes 
the subject matter of the network resource, for example, 
30 "dogs." In the Abstract attribute the Name File 64 stores 
information containing an abstract of the network resource. 
In the Type attribute the Name File 64 stores information 
describing a type of the network resource, for example, " 
RealAudio file". In the Audience attribute the Name File 64 
35 stores information describing the intended audience of the 
network resource, for example, "Women age 19-34". 

Defining metadata for a network resource, associating the 
metadata with a network resource, and storing a copy of the 
metadata on a server that contains the network resource in 
40 this manner offers significant advantages. For example, 
maintenance of the metadata is convenient. Since a copy of 
the metadata is stored locally on the server that contains the 
network resource, the metadata can be updated at any time 
without contacting a central service. As described further 
45 herein, a metadata crawler mechanism periodically visits the 
server to monitor changes in the metadata. If a Name File 64 
has changed, after validation, the changes are automatically 
propagated to the database and the index. 

In addition, in combination, the Name Files 64 operate as 
50 a distributed database of metadata. Maintaining a distributed 
database enhances scalability, because modifying the meta- 
data is not dependent upon the availability of a single 
centralized database. Further, by storing the metadata files in 
association with the server on which the network resources 
55 are stored, data integrity is improved. Only a user having 
authorization to store files on a server can create metadata 
mappings that reference network resources on that server. 

Yet another advantage is multi-lingual compatibility. The 
XML language supports the UNICODE character encoding 
60 standard. As a result, attributes stored in a Name File 64 can 
be expressed in any human language. 

Real Name System 

Using the metadata stored in Name Files 64, in combi- 
65 nation with a network resource locating system, attributes of 
a network resource can be used to locate the network 
resource. For example, the real name attribute of a Name 



6,151,624 

9 10 

File 64 can be used to locate a Web page. FIG. IE is a block 64 using a connection through the Internet 50. As indicated 

diagram of an embodiment of a network resource locating by path 28, the Crawler 24 can notify the Index 30 that the 

system comprising a Registry 10, a Librarian 20, an Index Index Files 34 need to be updated to reflect a change in the 

30, and a Resolver 40. information stored in the Name File 64. 

The Registry 10 includes a database 12 in the form of a 5 The Index 30 is coupled to the Registry 10. The Index 30 

commercial database system, such as the SQL Server, or a comprises an Index Builder 32 and one or more Index Files 

proprietary database. The Registry 10 provides a centralized 34 lhat an indcx of ^ real ^ real namc cntrics , 

storage point for mappings of red names to network and rcsourccs lo ^ systcm . For kj mc Index 

"^T^^f 35 ^.^"P^j^ 0 ™^ 7°" Files 34 have index entries for values stored in the Name 

ciatcd with the real names. In this context, real name refers r ~ , A „ . . _.. ~ A , , . 

to a name of a network resource expressed in conventional 10 ™ e M A F,l f? *} a * constn »< aed , managed, and 

syntax of a natural language, such as English, Japanese, u P dated b * me mdex BmM<!r 32 - 

Russian, etc. Each real name is required to be unique across Generally, in the preferred embodiment, the Index Files 
the Internet and unique within the Registry 10. The unique- 34 are more compact than the indexes maintained by con- 
fess of real names is enforced by the Registry 10. The ventional search engines, because the amount of information 
Registry 10 operates as a centralized, highly robust, and 15 represented in all the Name Files 64 is far less than the total 
scalable persistent storage area for all metadata. The Reg- content of all network resources available on the Web. Such 
istry 10 also stores statistics related to the usage of the compactness is a distinct advantage, providing greater seal- 
metadata in the context of various services that are built on ability and responsiveness than conventional search engines, 
top of the Registry, such as the GO navigation system In addition, the compact size of the Index Files 34 allows the 
described herein. 20 Index 30 to be replicated in multiple different geographic 

Real names, network addresses, and the descriptive infor- locations, 

mation are loaded into the Registry 10 by the Librarian 20. The Resolver 40 comprises one or more resolver pro- 

In the preferred embodiment, the Librarian 20 and the Index cesses Rl, R2, Rn, each of which is coupled respectively to 

30 communicate with the database 12 using an ODBC a Service 42, 44, 46. Each resolver process Rl, R2, Rn 

interface. In the preferred embodiment, the database 12 has communicates with its respective Service 42, 44, 46 to 

a capacity on the order of several hundred million entries. receive requests containing a real name, convert or resolve 

The Registry 10 and database 12 help ensure a consistent the real name into a network address associated with the real 

structure and vocabulary across Web sites. name, and forward the network address and other inform a - 

The Librarian 20 has a Registration Service 22 and a ^ lion associated with the real name to the requesting Service. 

Crawler 24, each of which is coupled to the database 12 and A client 70 is coupled to the Internet 50. The client is a 

to a network such as the Internet 50. The Registration computer, server, or network in which a Web browser 74 

Service 22 receives new mappings of real names to network runs under control of an operating system 72. An example of 

addresses, and descriptive information, and loads them into the Web browser 74 is Netscape Communicator®, and an 

or "registers" them with the Registry 10. The Registration 35 example of the operating system 72 is Microsoft Windows 

Service 22 receives the mappings from a client 70 over the 95®. The services of the real naming system are accessible 

Internet 50. The Crawler 24 traverses or crawls the Internet to the client 70 over the Internet 50 using the browser 74 

50, periodically connecting to registered Web servers that according to standard Internet and Web protocols, 

are connected to the Internet, to locale changes to the For example, under control of the browser 74 and the 

mappings stored in or in association with the Web servers. ^ operating system 72, the client 70 can establish an HTTP 

The real naming systcm interacts with one or more web connection through the Internet 50 to the Registration Ser- 

scrvcrs that are connected to the Internet 50. As an example, vice 22. The browser 74 retrieves pages or forms from the 

one Web Server 60 is shown in FIG. IB, but any number of Registration Service 22 that are prepared in the HTML 

Web servers can be used in connection with this embodi- language. The browser 74 displays the pages or forms. A 

ment. A local database 62 is coupled to the Web Server 60 45 user of the client 70 reads the pages, or enters information 

so that the Web Server can retrieve values from the local in a form and sends the filled- in form back to the Registra- 

database for use in web applications running on the Web tion Service 22. In this way, the client 70 and the Regis! ra- 

Server. tion Service 22 carry out a dialog by which a user of the 

A Name File 64 is also stored in association with the Web client 70 can perform functions offered by the system. 
Server 60 such that the Web Server can retrieve the Name 50 Preferably, the Registration Service 22, Crawler 24, Index 
File and forward its contents to the Internet 50 in response Builder 32, and Resolver 40 are one or more computer 
to a request. In the preferred embodiment, the Namc File 64 programs having the functions and procedures described 
stores one or more real name entries. Each real name entry herein. In one embodiment, each of the Registration Service 
contains a real name of a resource in the Web Server 60, a 22, Crawler 24, Index Builder 32, and Resolver 40 is an 
description of the resource, a network address, or other 55 independent process, and one or more instance of each such 
identifier of the location of the resource, and other in forma- process can be active and executing at a given time. In the 
tion about the resource such as its language and intended preferred embodiment, the computer programs are con- 
geographic region of use. Preferably, the Name File 64 also structcd using an object-oriented programming language 
stores an identifier of a grammar that is used to format the and related tools, such as the Java® language, 
other information in the Name File. In this way, the infor- Th e Registration Service 22, Crawler 24, Index Builder 
mation in the Name File is self-describing and language- 32, and Resolver 40 preferably execute on one or more 
independent. server computers that can rapidly access, manage, and 

In this context, the term "network address'* refers to an ' update the database 12 and index files 34. The foregoing 

unambiguous identifier of the location of a network elements can be distributed or segregated. For example, it is 

resource. An example of a network address is a URL. 65 contemplated that the Resolver 40 and its processes Rl, R2, 

As indicated by path 29, the Crawler 24 can contact the Rn execute on one server computer, and the Registration 

Web Server 60 and retrieve values stored in the Name File Service 22, Crawler 24, and Index Builder 32 operate on the 
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same computer or on a set of computers separate from the 
server that hosts the Resotver 40. In this configuration, the 
Resolver 40 can rapidly receive and respond to client 
requests for access to network resources that are indexed in 
the Index Files 34, without affecting or interfering with the 5 
other elements and their functions. 

In one embodiment, the Librarian 20, and other functions 
of the system, are accessed by connecting the client 70 to 
one or more administrative Web pages 80 that implement the 
functions, using an HTTP connection. The administrative 10 
Web pages 80 are hosted on a Web server and are generated 
by a Web server application that can communicate with the 
other elements of the system. The Web server application 
sends a top-level page to the client 70. The browser 74 of the 
client displays the top-level page, which presents a menu of 15 
options for working with the system. For example, preferred 
menu options are set forth in Table 1. 

TABLE 1 



TOP LEVEL MENU OPTIONS 



RNS FILE 
Create 
Activate 
Modify 

Delete 25 
STATS & BILLING 

Stats 

Billing 
CUSTOMER 

New Customer 

Modify Profile 30 

Change Contacts 

Logout 
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that enable a user to enter a new customer profile. The form 
has fields for entry of a name, address, telephone number, 
contact person, and payment method. The Web pages and 
forms are communicated to the client 70 and displayed by 
the browser. The user of the client 70 enters appropriate 
information into the data entry fields and clicks on or selects 
a "SUBMIT" button on the Web page. In response, the client 
70 returns the filled- in form in an HTTP transaction to the 
system. The system extracts the entered information from 
the fields and stores the information in a table of the database 
12. 

In the preferred embodiment, the Customer/New Cus- 
tomer registration process is initiated using a Web page 
generated by the system in the form shown in Table 2: 

TABLE 2— REGISTRATION HOME PAGE 

Welcome to the Real Name System registration site. 
Before you can submit your Real Name addresses, you need 
to provide us with some information about you and the 
organization that you may represent. 

To initiate the registration process, you first need to enter 
your email address as your login name, and select a pass- 
word. 

You will need to remember this login name and password, 
as the Real Name System uses them to grant you access 
privileges. 



Name 
Password 

[BACK] [NEXT] 



Each of the lop level menu options can be selected by 
moving the cursor generated by the client 70 over the name 35 
of the desired option, using the client's pointing device, and 
clicking on the desired option. The functions carried out by 
selecting each menu option are described below in the 
context of the functional module that carries out the func- 
tions. 40 

In the preceding discussion, the elements of the system 
have been described with respect to the Internet 50 as an 
interconnecting element. However, the Internet is merely 
one example of an interconnecting element that can be used 
to facilitate communication among the elements of the 45 
system. Other elements, such as local-area networks, wide- 
area networks, Intranets, and extra nets can be used. Also, the 
protocols that define the Internet, such as Transmission 
Control Protocol and Internet Protocol, are not required; 
other protocols are suitable and can be used 50 

In this configuration, the system has numerous advantages 
over prior approaches. For example, customer Web sites 60 
are isolated from the database 12. The Index Files 34 are 
separate from the database 12 and only the Index Files are 
accessed by the Resolver 40. This reduces database loading 55 
and increases responsiveness, and provides scalability. The 
architecture is well suited to distributed replication of the 
Index Files. 

Customer Profile Functions ^ 

In one embodiment, the system provides a set of customer 
information management functions that store, track, and 
update information about customers of the system. The 
information managed for each customer is called a customer 
profile. The customer profiles are stored in the database 12. 65 

When the Customer/New Customer option is selected, the 
system generates one or more Web pages containing forms 



In Table 2, the designations [BACK] and [NEXT] repre- 
sent function buttons. The user enters the user's email 
address in the Name field, and a user-selected password in 
the Password field. When the user clicks on the NEXT 
function button, the Name and Password are stored in the 
database 12 in association with one another. 

Preferably, the system then displays a Web page contain- 
ing a form that enables the system to receive further infor- 
mation about the user. The form has fields for entering the 
user's name, address, city, state, postal code, nation, and 
telephone number. The user enters the requested information 
and clicks on a NEXT button. The system checks each value 
to verify that it matches the proper data format required for 
the corresponding field, llie values are stored in the database 
12 in association with the user's name and email address. 
Collectively, this information is the customer profile. Once 
the customer profile is established, the user can create real 
name entries and store them in one or more Name Files 64. 

Selecting the Customer/Modify Profile option causes the 
system to generate a Web page containing a form that 
enables a user to change a previously entered customer 
profile. To ensure secure operation, the user's IP address is 
extracted from the HTTP transaction that the user used to 
request the Customer/Modify Profile option. The user is 
permitted to view and modify only that profile that corre- 
sponds to a previously created Name File that is stored on a 
server having the same IP address as the user. Based upon 
the user's IP address, the system looks up the corresponding 
profile in the database 12 and retrieves the contents of the 
profile. The contents of the profile are displayed in the Web 
page. 

The user may then move the cursor generated by the client 
70 to any of the data values displayed in the Web page and 
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enter modifications to the values. When the user selects or 
clicks on the "SUBMIT" button, the Web page containing 
the fiJled-in values are returned to the system in an HTTP 
transaction. The system updates the database 12 using the 
values in the page. 5 

Selecting the Customer/Change Contacts option enables 
the user to change the billing contact associated with a 
registered Name File. Selecting the Customer/Logout option 
enables the user to terminate the current session, or log in as 
a different customer. These functions are provided using a 10 
Web application that receives and loads appropriate values 
into the Registry. 

Registration Service 

FIG. 2A is a flow diagram of an embodiment of a 15 
preferred method of operating the Registration Service 22 of 
the Librarian 20. 

Preferably, the Registration Service 22 has a Web page 
interface by which one or more clients 70 can access 

20 

functions offered by the Registration Service by selecting 
function buttons of the Web pages to activate the functions. 

The primary function offered by the Registration Service 
22 is registration of new real names into the Registry 10. In 
one embodiment, the Registration Service 22 is invoked by ^ 
selecting the Create option from the top-level menu page. As 
shown in block 200, an external user or "customer" of the 
system identifies himself or herself to the system so that 
information entered later can be associated with the cus- 
tomer. This information includes an electronic mail address ^ 
of the customer whereby messages can be directed from the 
Registration Service 22 to the customer over the Internet 50. 
In this context, the terms "customer" and "user" refer to the 
operator of a computer remotely connected to the system, for 
example, the client 70. 35 

As indicated in block 202, the customer then provides 
information to the Registration Service 22 that identifies a 
network resource of the Web Server 60, by its location, its 
real name, and descriptive information about the network 
resource. For example, the customer enters the real name 40 
"Microsoft Internet Explorer," the URL http:// 
www.microsoft.com/ie4/ aboutie4.html, and a description 
about the resource. Preferably, this information is entered in 
Celds of a Web page that is constructed for the purpose of 
receiving the information, in the form shown in Table 3: 45 
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In block 205, the Registration Service 22 generates a file 
name at random for the Name Ffle 64. A random file name 
is used in order to prevent unauthorized programs, 
processes, or users from identifying or modifying the Name 
File 64 when it is stored in association with the Web Server 
60. If the same file name was used, at any Web server 
registered with the Registry 10, an unauthorized user could 
modify an entry stored in the Name File 64 to reference a 
different network resource. Eventually, as will be discussed 
further below, the Crawler 24 would detect the modification 
and store the new name in the Registry 10. Accordingly, it 
is desirable to hide the name of the Name File 64 from all 
unauthorized users. 

In block 206, the Name File 64 is sent as a file attachment 
to an electronic mail ("email") message to the customer. 
Block 206 includes the step of receiving an email address 
from the user. In the preferred embodiment, the system 
displays a Web page having a data entry field for the email 
address, in the form shown in Table 4: 

TABLE 4— EMAIL ENTRY PAGE 

Please enter your email address so that wc can send you 
the name file that you have just built 



nicofateentraaLcom 

[BACK] [NEXT] 



After sending the Name File 64 in an email to the user, the 
system displays a confirmation page at the client 70. In the 
preferred embodiment, the confirmation page has the form 
shown in Table 5. 

TABLE 5 



CONFIRMATION PAGE 

Your Name File has been mailed to the address nko@cc ntraaL oo m. You 
should now save this file on your Web tile according to the instructions in 
the email that you will receive. 

Once this step is Tn-m wp lwlwtt^ the file will have to be activated through 
the Real Name 61c activation service. (Simply follow the previous link, 
or in Customer Service, look Tor the menu item Activate under the 
RNS File category.) 

[FINISH] 



TABLE 3 



REAL NAME ENTRY PAGE 



Real Name: 


Microsoft Internet Explorer 


URL: 


http^/www^qy^ft^IIlflyf/ 




aboulie4.html 


Type: 


Company 


Language: 


English 


Region: 


North America 


Description: 


This is the home page for Internet 




Explorer. 




[BACK] [NEXT] 



When the user has entered all the information, to continue 
processing of the Name File 64, the user clicks on the NEXT 60 
function button at the bottom of the page. In response, as 
shown in block 204, the Registration Service 22 constructs 
a Name File 64 based on the information entered by the 
customer. At this point, the Name File 64 is stored on a 
server accessible to the Registration Service 22. However, 65 
the Name File 64 is not yet stored in association with the 
Web server 60. 



In block 208, the customer installs the Name File 64 in the 
Web Server 60 or in a manner that is accessible to the Web 
Server. Preferably, the Name File 64 is stored in a location 
on the Web Server 60 that is specified by the Registration 
Service 22. For example, the email specifies that the Name 
File 64 shall be stored in the root directory of the network 
resource that is named in the Name Ffle 64. This is done to 
ensure that the receiving customer individual is authentic; 
the Registration Service 22 presumes that only an authentic 
customer representative would have root directory access to 
the Web server on which the named network resource is 
located. The root directory is also specified for the conve- 
nience of the customer. When the Name File 64 is stored in 
the root directory of the Web server, the customer can 
modify or re-organize the Web server without affecting the 
Name File. Conversely, if the Name File 64 was stored in a 
subordinate directory of the Web server, then there would be 
a risk of disabling the Name File by accidentally deleting its 
directory. 

In block 210, the customer confirms to the Registration 
Service 22 that the Name File 64 has been stored in the 
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specified location by the customer. The customer confirma- 
tion can be provided in an email directed to the Registration 
Service 22 or by entering an appropriate command using the 
Web interface of the Registration Service 22. 

Thereafter the user is required to activate the Name File. 
Activation is a process of verifying that the Name File is 
stored in the correct location by an authorized user. 
Optionally, the activation process also includes the process 
of arranging payment for the privilege of having a registered 
Name File recognized by the system. One embodiment of an *0 
activation method is shown in FIG. 2B. 

In the preferred embodiment, the user activates a Name 
File after creating it by selecting the RNS File/Activate 
function from the top-level menu option list. In response, as 
shown in block 212, the system constructs a page that 
requests the user to enter a type of activation, and sends the 
page to the client, which displays it. For example, the system 
displays a page of the form shown in Table 6: 

TABLE 6 

ACTIVATION TYPE SELECTION PAGE 

Please select the appropriate service: 
(*) live update of a previously registered Name File. 
(") Registration of a new Name File on your website. 
[BACK] [NEXT] 

Preferably the symbols shown in the form "(*)" in Table 
6 above are displayed as radio buttons, or another graphic 
clement, that can be selected by the user. 

When the user selects the first option ("Live update of a 
previously registered Name File ), as shown in blocks 
214-216, the system activates the Crawler, which locates the 
user's Name File over the Internet, and updates the database 
12, as described below. Thus, the "Live update" function 
provides a way for a user to force the system to locate a 
modified Name File and update itself with the new infor- 
mation. Alternatively, as described below in connection with 
the Crawler, the user may simply wait and the Crawler 
eventually will locate the modified file and update the 
database. 

When the user selects the second option ("Registration of 
a new Name File on your website"), as shown in blocks 220 
to 222, in response the system constructs and sends to the 
client 70 a Web page with which the user can enter payment 
information pertaining to the user and its Name Files. 
Payment steps of the activation process are an entirely 
optional part of the process, and other embodiments are 
contemplated that omit any payment mechanism. In the 
embodiments that do use a payment mechanism, the Web 
page contains fields that accept entry of payment informa- 
tion. For example, the fields enable entry of a credit card 
type, card number, expiration date, and cardholder name. 
The system receives the payment information values in 
block 224. 

In block 226, the system prompts the user to enter the 
network address of the Name File to be activated, and a 
description of the Name File. 

In block 228, the Registration Service 22 establishes an 60 
HTTP connection to the Web Server 60, requests and 
uploads a copy of the Name File 64. This step is carried out 
to verify that the Name File 64 is valid and is stored in the 
correct location. In block 230, the Name File 64 is parsed, 
and values identifying the network resource are extracted. In 65 
block 232, the system constructs a Web page that displays all 
the entries parsed from the current Name File 64, and sends 
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the page to the client 70. Within the Web page, the system 
displays a prompting message, such as the following: 

"The Name File that we have downloaded from your site 
contains the following entries. Please verify these entries are 
correct. Press NEXT to continue. 



[BACK] [NEXT]" 

As shown in block 234, the user reviews the entries, 
verifies that they are correct, and clicks on the NEXT 
function button. If any of the entries is not correct, the user 
clicks on the BACK function button, which provides access 
to the MODIFY function described herein. 

In the preferred embodiment, the system then displays a 
Web page containing a written legal agreement governing 
payment of registration fees and resolution of disputes 
involving real names or domain names, as shown in blocks 
236-238. The agreement concludes with function buttons 
labeled ACCEPT and DECLINE. To accept the terms of the 
agreement and proceed with registration, the user clicks on 
the ACCEPT button. To decline the terms of the agreement 
and discontinue the activation process, the user clicks on the 
DECLINE button. Use of the legal agreement is entirely 
optional and embodiments that do not use such an agreement 
are contemplated and are within the scope of the invention. 

The system then stores values parsed from the Name File 
64 in the database 12 of the Registry 10, as shown in block 
240. 

For security reasons, the network address or URL of the 
Name File 64 must match the root directory of the Web 
server 60. This prevents redirection of real names to unau- 
thorized different network addresses. It also prevents the 
owner of the Web server 60 from redirecting to that Web 
server any real name that he or she does not own. 

In block 242, the Registration Service 22 notifies the 
Index Builder 32 that a new entry has been made in the 
database 12. Path 26 of FIG. IB represents the notification. 
The notification includes information sufficient to identify 
the new entry in the database 12, for example, a row 
identifier ("rowid") of a table in which the new entry is 
stored. In response, the Index Builder 32 carries out a live 
update of the Index Files 34, in the manner discussed further 
below. 

Thus, the Name File 64 created by the user is activated 
and available for use by the Resolver 40. 

In the preferred embodiment, the database 12 is available 
to receive queries from registered members of the system. 
As a result, a registered member can submit queries to the 
database 12 that request the database to display currently 
registered information about network resources or Web 
pages of other organizations. Accordingly, if another regis- 
tered user succeeds in registering information that misrep- 
resents the content of that user's network resources, the 
misrepresentation can be reported to the Registry for cor- 
rective action. Thus, in this manner, the formality of the 
registration process, and the open query capability of the 
database 12 enable the present system to avoid the deception 
that is possible through the improper use of metatags. 

Modifying and Deleting Name File Information 

After a Name File is created having one or more entries, 
the entries can be edited or deleted using the RNS File/ 
Modify and RNS File/Delete functions shown in the lop- 
level menu list. 
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When the user selects the RNS File/Modify function, the 
system reads the RNS file from the server associated with 
the user, and displays the contents of the file in a Web page 
having the form shown in Table 7. 

TABLE 7 

RNS FILE/MODIFY PAGE DISPLAY 

The current list of RNS entries contained in youi RNS file is shown 
below. To edit an entry, select the appropriate word and press EDIT. 
To delete an entry, select the appropriate word and press DELETE. 
To add a new RNS entry, press ADD. Press NEXT when you arc 
done editing the RNS file. 
[BACK] [EDIT] [DELETE] [ADD] [NEXT] 
Real Name: Nico Popp 

URL k"P^faicp,ff'ttn»aLcoiB 
Type: Company 
language: English 
Region: Global 
Description: Nioo's Page 

Selection: 

Real Name: Keith Teare 

URL: http:Zftoth.centraal.oorq. 
Type: Company 
Language: English 
Region: Global 
Description.: Keith's Page 

Selection: 
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The page consists of a text instruction section, a set of 
editing function buttons, and a list of entries currently 
contained in the Name File. The text instruction section 
explains the functions carried out by the editing function 
buttons. In the preferred embodiment, the function buttons 
of this page operate on entire Name File entries rather than 
individual fields within each entry. For example, to edit an 
entry, a user selects the appropriate real name, such as 
"Keith Teare" and presses the EDIT function button. In 35 
response, the system displays an entry editing page that 
contains the selected entry. The user can enter modified text 
in fields of the entry editing page. 

Similarly, to delete an entry, the user selects the appro- 
priate word and presses the DELETE function button. In 40 
response, the system constructs a new Name File that 
contains all the prior entries except the entry selected for 
deletion. 

To add a new entry to the currently displayed Name File, 
the user clicks on the ADD function button. In response, the 
system displays a page in the form of Table 3 discussed 
above in connection with creating a new Name File. 

To apply changes made in the EDIT, DELETE, or ADD 
operations, the user presses the NEXT function button. 
Selecting the NEXT function button causes the system to 
construct a new Name File, preferably in the above- 
described XML format. The system emails the new Name 
File to the user in an appropriate explanatory message. For 
security reasons, the user is required to store the new Name 55 
File in a directory specified by the system, as in the case of 
creation of a new file. 

Crawler 

FIG. 3 is a flow diagram of an embodiment of a method 60 
that is preferably carried out by the Crawler 24. In the 
preferred embodiment, the system includes a Scheduler 
process that triggers activation and execution of the Crawler 
24. For example, the Scheduler stores a schedule of events. 
An event states that the Crawler 24 should execute every 65 
twenty-four hours. Upon the occurrence of a scheduled 
event, the Scheduler launches the Crawler 24. 
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In block 302, the Crawler 24 reads the database 12 of the 
Registry 10 and retrieves one or more rows or records that 
identify network resources that are indexed in the Index 
Files 34. The protocol for selecting the rows or records is not 
critical, and several different schemes can be used. For 
example, the Crawler 24 can select all rows or records that 
have not been updated since the last time that the Crawler 
executed. Alternatively, the Crawler 24 can select all rows or 
records that have been created within a specified time frame 
or that are older than a particular number of days. In still 
another alternative, the Crawler 24 selects the least recently 
updated record. In a preferred embodiment, the system 
includes a mapping of real names to RNS file names and 
locations called the File Info table. The Crawler matches the 
selected rows to the File Info table and locales the network 
address, location or URL of the Name File associated with 
each real name, row or record. 

For each of the selected rows or records, in block 304, the 
Crawler 24 polls the customer Web site that is represented by 
the row or record, searching for updates to the Name File 64 
that is stored in association with that Web site. The polling 
step includes the steps of opening an HTTP connection to 
the Web site, requesting and receiving a copy of the Name 
File. The Crawler 24 parses the Name File, using an XML 
parser, to identify real name entries, and values within each 
real name entry, that specify the real name, network address, 
and descriptive information relating to network resources. 
An XML parser is commercially available from Microsoft 
Corporation. 

For each entry in the Name File, as shown in block 306, 
the Crawler 24 tests whether the entry matches a row or 
record in the database 12. Thus, the Crawler 24 determines 
whether the contents of the Name File are different from 
entries in the database 12. If so, as shown in block 308, then 
the Crawler 24 updates the database 12, and requests the 
Index Builder to rebuild the index entry associated with the 
updated row or record in the database 12. 

In this way, the Crawler 24 polls Web sites on the Internet 
50 to locate customer sites that have updates. Because the 
Name Files are distributed across the network at numerous 
customer sites, each customer has the freedom and flexibil- 
ity to modify its Name File at any desired time. The 
customer need not notify the real name system, because the 
Crawler 24 will eventually locate each change and update 
the database 12 accordingly. Thus, the Librarian 20 auto- 
matically monitors changes to Name Files distributed across 
the network, and periodically updates the Registry 10 with 
the change. Advantageously, customers or end users are not 
involved in updating the database 12; the Crawler 24 
updates the database automatically. 

In the preferred embodiment, a customer can instruct the 
Librarian 20 to immediately execute the Crawler 24 with 
respect to a specific Web site. In this way, changes to a 
particular Name File are immediately identified and loaded 
into the database. The customer activates immediate execu- 
tion of the Crawler 24 by selecting the Live Update option 
from the top-level menu. In the preferred embodiment, the 
system also carries out, once weekly, a comprehensive 
update of the Index Files 34 based on the contents of the 
database 12. In this way, at least weekly, the Index Files 34 
are rebuilt based on the current contents of the database 12. 

In an alternate embodiment, the Crawler 24 also validates 
each of the network resource locations that are identified in 
each Name File. For example, the Crawler 24 attempts to 
connect to and load each network resource that is identified 
in a Name File entry. If an error occurs, an appropriate email 
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message is composed and sent to the contact person of the 
organization that registered the Name File. The email mes- 
sage advises the contact person that the network resource 
location in the Name File is invalid. 

Index Builder 
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The Index 30 comprises an Index Builder 32 and Index 
Files 34. The Index Builder 32 is a software program or 
process that operates in two modes. In the first mode, a 
Reconstructor process of the Index Builder 32 periodically 
polls the database 12, discovers changes to the database, and 
indexes the changed real name records in the Index Files 34. 
In a second mode, the Index Builder 32 updates the Index 
Files 34 in real time, based upon a queue of requests to 
update the indexes. FIG. 4 is a block diagram of a preferred 
embodiment of the Index Builder 32. Computers labeled GO 
Machines 100, 102, 104 each run an instance of the Index 
Builder 32. Each GO Machine 100, 102, 104 is associated 
with a network interface process Ml, M2, Mn of a Queue 
Agent 92a The Queue Agent 92a is coupled to a network 20 
106, such as a local area network, and receives requests to 
build index entries from the Librarian 20. The Queue Agent 
92a propagates a copy of each request to one of the network 
interfaces Ml, M2, Mn, which forwards the request to its 
associated GO Machine 100, 102, or 104. This architecture 
is highly responsive to external queries, and is fault-tolerant 

Within each GO Machine, the Index Builder 32 is coupled 
to a pair of queues 90a, 90b and a pair of indexes 34a, 346. 
The GO Service 42 can access either of the indexes 34a, 
346, but always accesses only one of the indexes at a time. 
The Resolver 40 is omitted from FIG. 4 for clarity, but it 
should be understood that the GO Service 42 accesses each 
index 34a, 346 through a Resolver 40 process. 

It is important for the GO Service 42 to be in constant 
communication with one index or the other. Accordingly, 
using the architecture shown in FIG. 4, the Index Builder 
builds the indexes using the following process. The GO 
Service is placed in contact with index 346 and instructed to 
communicate real name resolution requests only to index 
346. As index build requests arrive from the Queue Agent 
92a at the Index Builder 32, the Index Builder 32 adds the 
requests to both of the queues 90a, 906. When one of the 
queues is sufficiently full, for example, queue 90a, the Index 
Builder 32 sequentially removes entries from the queue, in 
first- in -first -out order, and updates the index 34a with each 
queue entry. Concurrently, if any new index build requests 
are received, they are routed to both of the queues. When the 
queue 90a is empty and the index 34a is fully updated, the 
Index Builder 32 instructs the GO Service 42 to communi- 
cate real name resolution requests only to index 34a. The 
Index Builder 32 then removes entries only from queue 906 
and updates only index 346 from that queue. Thus, the Index 
Builder 32 can add index entries to either of the queues 90a, 
906, but always updates only one index at a time using the 
contents of only one of the queues at a time. The queue with 
which the Index Builder 32 communicates is always the 
opposite or complement of the indexes 34a, 346 with which 
the GO Service 42 is currently communicating. In this way, 
the GO Service 42 constantly communicates with an index, 
and the Index Builder 32 can update the index in real time 
without disrupting name resolution operations. 

Preferably, the index build requests comprise an identifier, 
called a File Id, of a file or row that is mapped in the File Info 
table described above. The Index Builder 32 looks up the 
FilelD in the File Info table and retrieves all entries in the 
database that match the FilelD. Each database entry includes 



a unique identifier that is associated with a network resource 
that is described in the database entry. The unique identifiers 
are generated using a sequence facility of the database 
server. Based on the unique identifier, for database entry that 
5 matches the FilelD, the Index Builder retrieves a matching 
index entry. The information in the index entry is compared 
to the information in the build request. If the information in 
the build request is different, the index entry is updated. If 
the information in the build request indicates that the asso- 
10 ciated network resource has become inactive or unavailable 
in the network, the index entry is deleted. 

To provide scalability, reliability, and rapid response, each 
of the GO Machines 100, 102, 104 has a similar configu- 
ration and operates in parallel Although three GO Machines 
100, 102, 104 are shown in FIG. 4 as an example, any 
number of GO Machines can be used in the system. In the 
preferred embodiment, a Scheduler process determines 
when the Index Builder 32 executes. 
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Resolver 

Generally, the Resolver 40 functions as a runtime query 
interface to the metadata that is stored in the Registry 10. 
The Resolver 40 functions to receive real name requests 
from services 42, 44, 46, query the index 30 to identify 
network addresses corresponding to the real name requests, 
and respond to the services with the network addresses. The 
Resolver 40 is structured to respond rapidly to query opera- 
tions and to service millions of requests per day. To maxi- 
mize response time and ensure scalability, the Resolver 40 
does not directly access the database 12 of the Registry 10 
in responding to queries. Instead, the Resolver communi- 
cates with the Index 34 that is stored in fast main memory. 

In the preferred embodiment, the Resolver 40 operates in 
any number of multiple instances Rl, R2, Rn, each of which 
is associated with a service 42, 44, 46 that is making a 
request to the Resolver. The services 42, 44, 46 communi- 
cate with Resolver instances Rl, R2, Rn using HTTP 
connections. Further, it is preferred to operate the computer 
hardware on which the Resolver 40 runs in a triple- 
redundancy configuration. This configuration provides rapid 
response to the requesting services 42, 44, 46 and provides 
reliability. Each instance Rl, R2, Rn is implemented as an 
instance of a Web application that implements the Resolver. 
The services 42, 44, 46 communicate with Resolver 
instances Rl, R2, Rn using HTTP connections. 

In one embodiment, an instance of the Resolver 40 is 
implemented as a dynamically linked library (DLL) that is 
integrated into the services 42, 44, 46. In the preferred 
embodiment each instance of the Resolver 40 is a detached, 
separate process or program that operates according to the 
method shown in FIG. 5. The Resolver 40 is implemented 
with one or more APIs that allow the development of 
services that use the Resolver, such as "yellow pages" and 
search services. 

As shown in blocks 502—504, an external web client, 
server or browser, such as the client 70, accesses the 
Resolver 40. In one embodiment, the client 70 connects to 
the Resolver 40 using an HTTP connection. In block 502, 
the client 70 establishes an HTTP connection to the Resolver 
40. In block 504, the client 70 provides a URL to the 
Resolver that requests the network address corresponding to 
a particular real name. For example, the URL is in the form 
http ://www. resolver.com/resoI ve?rn=REAL NAME. In a 
URL of this form, "http://" identifies the URL as an HTTP 
request, www.resoIver.com is the server domain, and 
"resolve" is the name of a program running on that server 
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domain thai implements the resolver. The statement "ra- provided with an XML parser that can convert the XML file 

REAL NAME" passes the value "REAL NAME" to a produced by the Resolver 40 into text or other information 

parameter "m" that is recognized by the resolver. in a format that is usable by the client 70. Also in the 

In another embodiment, the client 70 connects to one of preferred embodiment, each entry referenced in the Entry 

the services 42, 44, 46 associated with an instance of the 5 Set object contains a usage vahic that indicates the number 

Resolver 40. The services 42, 44, 46 communicate with the of limes »hat the entry has been resolved. The usage values 

client 70 to request and receive a real name. 416 uscd to order lhc entries when they are displayed or 

Thus, in one of these ways, the Resolver 40 receives a real otherwise used by one of the Services 42-*6. 

name requested by the client 70. In response, the Resolver After each real name resolution, the Resolver 40 writes an 

40 constructs a Qualifier object in main memory that con- 10 cntr y in a log file 84 that describes the real name, the total 

tains the real name. In block 506, the Resolver connects to number of times it has been resolved in the past including 

the Index 30 and submits a query requesting the network mc current resolution, the IP address and domain name of 

address or URL that corresponds to the real name in the *e client or server that requested the current resolution, and 

request from the client 70. In the preferred embodiment, the the time at which the current resolution occurred, 

query is submitted by sending a message containing the 15 In the preferred embodiment, the Index 30 and the 

Qualifier object to an Index Store object. The Index Store Resolver 40 execute on the same physical computer, and the 

object encapsulates or provides an abstract representation of Index Files 34 are stored in main memory of that computer, 

the Index 30. The Index Store object executes an index This configuration improves response time of the Resolver 

query. 40 by providing it with high-speed access to the Index 30. 

In block 508, the Resolver 40 receives a response from the 20 It is contemplated that the Resolver 40 will respond to 
Index 30 that contains the network address or URL that several tens of millions of real name resolution requests per 
corresponds to the real name in the request from the client day- Also in the preferred embodiment, the Index 30 and the 
70. In the preferred embodiment, the Index Store object Resolver 40 are implemented as a plurality of Component 
returns an Entry Set object to the Resolver 40. The Entry Set Object Model (COM) programmatic objects that commum- 
object contains or references a set of one or more entries 25 cate with the AltaVista runtime library using AltaVista's 
from the Index 30 that correspond to the requested real API. The AltaVista runtime library is commercially avail- 
name. Each Entry Set object has a method that can supply able for license from Digital Equipment Corporation in the 
the location or URL of a network resource described in an form of the AltaVista Software Development Kit (SDK), 
entry of the object. ^ In an alternate embodiment, the Resolver 40 is capable of 

The Index Store object also has logic for ordering entries distinguishing among network addresses that refer to 
in the Entry Set object based on a function of past usage. resources located on the Internet, an internal business net- 
When the Entry Set object has just one entry, ordering is not work or "intranet", and an externally accessible internal 
needed. When the Entry Set object has more than one entry, business network or "extranet". In an intranet environment, 
a two-stage ordering process is carried out. First, the entries 35 the Resolver 40 accesses a Registry 10 that is located within 
are ordered according to relevance. Second, entries having the organization that owns and operates the Resolver. The 
equal relevance are ordered based upon a function of the Registry 10 stores resource information that identifies intra- 
number of past resolutions for each entry. net resources. The Resolver 40 resolves real names entered 

For example, consider a query for the real name address by the u ^ r into the locations of intranet resources, and 
" Microsoft." Assume that resolution of the query yields no ' 40 navi 8 ates <*» 11X1 to lbem - 

exact match, but yields more than one inexact match; such „ ' 
as "Microsoft Excel" and "Microsoft Word". In the first 

stage of the ordering process, these two entries would be The services 42, 44, 46 can be implemented in several 

ranked against relevance criteria and re-ordered if one entry variations. In one embodiment, the GO service 42 is a 

is determined to have greater relevance to the query than the 45 computer program that is installed into or attached to the 

other. The relevance criteria include, for example, the num- browser 74 of the client 70. For example, the GO service 42 

ber of words in each entry, whether each entry contains the is installed into the client 70 as a plug-in to the browser 74. 

exact query term, etc. In this example, according to these The user downloads the GO service 42 from a central 

criteria, each of the two entries has equal relevance; distribution site and stores the service on the client 70. The 

therefore, they are not re -ordered. In the second stage of the 50 user executes an installation program that installs the service 

ordering process, the Resolver 40 retrieves statistical infor- into the browser 74. Once installed, the GO service 42 

mation about each entry from the Statistics Service intercepts network resource names entered by the user into 

described herein. The statistical information includes a the browser 74 and resolves the names into network 

usage value for each real name entry that is computed by addresses that are usable by the browser 74. 

applying a weighting function to a count of past resolutions 55 FIG. 6 is a block diagram of a method of operating the GO 

for that real name. The weighting function operates to give service 42 in this configuration. FIG. 10 is a diagram of a 

more weight to recent resolutions for the real name than to user interface display 1000 generated by the GO service 42 

resolutions that occurred in the distant past. The Resolver { n this configuration. In block 600, the user invokes or 

com pa res the usage values for each of the entries and initiates execution of the browser 74. The browser 74 has a 

re-orders the entries, if necessary, so that the entry having 60 URL data entry field into which a user customarily types a 

the highest-weight usage value is first in order in the Entry network address of a document to be retrieved and displayed 

Set object. by the browser, such as a URL. In block 602, the user enters 

In block 510, the Resolver 40 formats the response of the a real name into the network address data entry field. In 

index into an output message. In a preferred embodiment, block 604, the GO service 42 captures all keystrokes that are 

the Resolver 40 constructs an XML file containing the 65 typed by a user into the network address data entry field of 

information in the response from the Index 30. In the the browser 74 and thereby receives the real name entered by 

preferred embodiment, the services 42, 44, 46 each are the user. 
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In block 606, the GO service 42 looks up the real Dame If the real name is not in the override table 76, as tested 

entered by toe user in an override table 76 stored in the client in block 608, then control is passed to block 609. In block 
70. The override table 76 persistently stores mappings of 609, the service 42 requests the Resotver 40 to resolve the 

real Dames to network addresses or URLs. ITrc mappings are network resource name received at the browser into a 
established by the user or the client 70, using a function of 5 network address. For example, the service 42 constructs a 

the GO service 42 to initially set up and update the override URL that references a predetermined location of the system 

table 76. The override table 76 is stored on the client 70, for that implements the Resolver 40. The URL contains, as a 

example, on the hard disk or other non-volatile storage parameter to be passed to the Resolver 40, the network 

device of the client 70. resource name received at the browser. The service 42 opens 

The override table 76 provides a way for the user to 10 an HTTP connection from the client 70 to the Resolver 40 

establish a personal list of mappings of real names to using the URL that contains the network resource Dame. The 

network addresses. Thus, the override table 76 can be used Resolver 40 extracts the value of the network resource name 

as a "personal address file". For example, a user can estab- ^ mm ^ c URL, and carries out the resolution process 

lish an entry in the override table 76 that maps the symbol described above. The Resotver 40 then returns one or more 

u $" to the domain name "quote.yahoo.com". Thereafter, 15 network resource location values in an H i" I F message to the 

when the user enters the symbol "S" into the network browser 74. 

address data entry field of the browser, the GO service 42 If one network resource location value is received from 

will cause the browser to retrieve the resource named the Resolver 40, then in block 610, the GO service 42 

"quote.yaboo.com". Using the override table 76, the user redirects the browser 74 to the network address found by the 

also can establish an explicit mapping between a real name 20 Resolver 40. For example, the service 42 extracts the 

which, if submitted to the Resolver 40, would resolve to a network resource location value from the HTTP message 

list of network addresses. received from the Resolver 40, and passes the value to 

As shown in FIG. 10, the override table 76 is displayed in functions of the browser 74 that can load and display Web 

an address table pane 1010 of the user interface display pages- The browser 74 then loads and displays the file or 

1000. Real names of network addresses are displayed in a 25 P 3 ^ located at the network address in conventional manner, 

name column 1012, and corresponding network addresses Alternatively, if more than one network resource location 

are displayed in a network address column 1014. Descrip- value is received from the Resolver 40, then in block 610 the 

lions of the real names are displayed in a description service displays a list of the network resource location 

column. The user interface display includes a menu bar 1016 values. The results are displayed in an order, from most prior 

and function buttons 1018. The menu bar 1016 has a 30 resolutions to least prior resolutions, based on the resolution 

plurality of keywords (Addresses, View, Edit, Options, values compiled and stored by the Statistics Service 82. In 

About Go!) that provide access to a drop-down menu another variation, the service returns to the client 70 an 

associated with each of the functions identified by the HTTP response containing an XML in which the results of 

keywords. The function buttons 1018 are used for rapidly the query are stored. 

selecting functions provided in the drop-down menus. 35 In an alternate embodiment, the GO service 42 is imple- 

The Address drop-down menu provides functions named mented as a Web application that runs on a dedicated Web 

Close, Save, Activate, and Exit. The Close function closes server. To locate a network resource, the client 70 connects 

the user interface display 1000 and terminates the service. to the GO Web server using a predetermined network 

The Save function saves the real names and corresponding ^ address or URL. In response, the Web application of the GO 

network addresses in a file. The View drop-down menu service 42 displays a Web page comprising a form with a 

provides functions named Large Icons, Small Icons, List, data entry field. The end user types the real name of a 

and Details. The functions of the View drop-down menu network resource into the data entry field. The GO server 42 

change the form of display used in the address table pane locales the network resource in the manner described above. 

1010. For example, when the Large Icons and Small Icons 4J In another alternate embodiment, the GO service 42 is 

options are selected, respectively, the display shows each linked to a button or panel that is embedded in a Web page 

entry in the override table 76 as a large or small icon. When of an external Web server. The button or panel is anchored 

the List option is selected, the override table 76 is displayed to a network address or URL that invokes the GO service 42 

in the form of a simplified list that shows only the real name when the button or panel is selected by a user viewing the 

associated with each entry. When the Details option is 5Q external Web server. This configuration provides a way to 

selected, the override table 76 is displayed as shown in FIG. enter real names that does not require use of a browser. 

10, in the form of a detailed list. If the test of block 608 is affirmative, then the network 

The Edit pull -down menu has functions named Insert and resource name entered by the user is located in the override 

Delete. The Insert function enables a new entry to be added table 76. In that case, as shown in block 612, the service 42 

to the override table 76. When the Insert function is selected, 55 retrieves the corresponding network resource location from 

the service displays a pop-up window and prompts the user the override table 76. The service 42 then redirects the 

to enter a real name, URL or location identifier, and descrip- browser to the network resource at that location, 

lion. The pop-up window also has SAVE and CANCEL In yet wotiin alternate embodiment, the GO Service 42 

function buttons. When appropriate data is entered, the user includes a mechanism to detect and respond to the natural 

clicks on the SAVE function button to add a new entry to the & language being used by the client 70 that contacts and 

override table 76. provides a query to the GO Service. Assume the computer 

The Options pull-down menu provides functions that that is running the GO Service 42 operates using UTF-8 

access other features of the service. For example, a Resolver character set encoding and the English Language, whereas 

option is provided that enables the user to change the the client 70 is using the Japanese language and a different 

resolution mechanism used by the service from the Resolver 65 character set encoding. When the GO Service 42 sends a 

40 to an external domain name resolution service available Web page to the client 70 that contains the real name entry 

over the Internet 50. form, the Web page includes a hidden field that stores a 
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pre -determined text string. The client 70 receives the Web An application program running on the Web application 

page, and its browser or operating system converts the Web server 60a communicates with the Resolver 40 through the 

page to the character set that it uses. The user of the client Internet 50 over paths 40a, 40b using CGI scripts to generate 

70 enters a real name into the Web page and submits it to the HTTP requests and responses. The Web application server 

GO Service 42. The GO Service 42 receives the Web page, 5 60a uses calls to functions provided by the API of the 

extracts the value of the hidden field, and compares the Resolver 40 to communicate along paths 40a, 40b. Using 

hidden field value to a table or mapping of hidden field ibis structure, the Web application server 60a issues requests 

values to character set encodings and languages. The GO ^ning queries to the Resolver 40. In response, the 

Service 42 retrieves the corresponding character set encod- Rcsolver 40 evaluates the query, queries the Index 30, and 

mgandlarujuage.Basedonmel™^ 1Q a ^ of mctadata for ^ i^ ex enUies reflecting Wcb 

selects a resource having a matching Language value in the ^ malch mc ^ scl of meladala fe packaged 

metadata section 906 of the resource: In tins way, the system as an XML file and delivered to the Web application server 

transparently determines the language of the client that ^ b ^ Rcsolvcf 40 ^ Wcb application 60fl has 
originals a query, and supplies a resource that is appropriate . M xm^^ that can parse the XML code in the XML file, 

to that language. 15 Based on me parsed XML code, the Web application server 

In another alternate embodiment, the GO Service 42 and 60o creates one or more HTML documents and delivers the 

the Resolver 40 use the values of the metadata in the Name documents to the client 70. The client 70 displays the 

Ffle 64 associated with resources to respond to advanced HTML documents to the end user, 
queries. For example, assume that United Airlines registers 

a Name File 64 that describes resources in several different) ^ Statistics Service 

languages such as English, French, and Japanese.' A user » , , , , - - ... 4 , n , .„ 

. . * . ... f . ' . , ,, . , . - 1 - As described above id connection with the Resolver 40, 

desires to locate a Web site affiliated with United Airlines ... , . . . , . . 

. , , . _ , . , „ , , each time a real name resolution is carried out by the 

that is located in France or prepared in the French language. n . .... , C1 . „ . , 

, , J.. 1 . , .... „ „ - . Resolver, it writes a log file entry. The system includes a 

The user enters the words United Airlines France mto the c ,„ t - ..• c r - « ,.° • ' ... t ' 

„ • « n , H . . t . t . Statistics Service 82 that is responsible for reading the log 

GO Service 42. The Resolver 40 attempts to match the C1 . , . , „■ - , c , - t ,? . , 

, _ r „ - . - 25 file and loading information from the log file into the Index 

words to the Description, Region, and Language fields of the 34 

metadata section 906 associated with the United Airlines' t . . 

Name File 64. The Resolver 40 and the Go Service 42 In the Preferred embodiment, the Statistics Service 82 

redirect the user's browser to a United Airlines site located operates penod.cally on scheduled basis. The Statistics 

in France Service 82 reads each record of the log file and constructs an 

. ",. . ... , t , „ . . 30 index object based on the information in the log file. The 

In an alternate embodiment, when the GO Service 42 is „„ J „ „_ „, , . . . 

, . . , . . . , „ , . t . .. , _„ Statistics Service 82 then sends a message to the Index 

implemented as a browser plug-in installed m the client 70, ... ,~ „ A jL , , .,, & 4 ■ . 

lL c. j L . j- • c ^ Builder 32 that requests the Index Builder to persistently 

the uO Service provides character encoding information to A At _ , . ~! , , - . . ... 

.. „ , .„ T . • . , _^ 0 . store the values in the Index riles 34. In response, the Index 

the Resolver 40. To obtain the character encoding currently _ A , .... ,r, . 

* * 1 . _ A „. . Builder 32 stores the values m the Index Files 34. 

used on the client 70, the GO Service 42 calls an operating 35 

system function of the operating system that runs on the ^ top-level menu page of the system has hyperlinks that 

client 70. The GO Service 42 attaches the character encod- enable ^ uscr 10 acccss statistics and billing functions, 

ing information to the URL that is used to return the user's When the Statistics & Billing/Statistics option is selected, 

query to the Resolver 40. In this way, the Resolver receives system generates a Web page 700 in the form shown in 

information indicating the language and character set cur- 40 FIG. 7A The Web page 700 has a list 702 of top-level 

rently used by the client 70, and can respond with a network options. A set of function buttons 704 enable the user to 

resource that is appropriate to that language. establish other global functions such as resolving an address, 

In another alternate embodiment, the computer system entering new customer information, obtaining customer 

further includes a microphone coupled to an analog-to- service, and learning more information about the real name 

digital converter. The analog-to-digital converter is coupled 45 sys^ 111 - 

through an appropriate interface to the bus of the computer Report function buttons 706 enable the uscr to acccss 

system. Under control of driver software or another appro- report generation functions of the system. In an 

priate application program, the analog-to-digital converter embodiment, the report function buttons 706 include a 

receives an analog audio input signal from the microphone Select Entries button 712, a Select Time button 714, a Report 

and converts the signal to a digital representation of the 50 EnfcT button 716, and a Report per Origin button 718. 

signal. The driver or application program receives the digital The Select Entries button 712 is used to identify a range 

representation and converts it into a phoneme, string of of entries within a Name File for which statistics are to be 

words, keyword, or command for the GO Service 42. The generated. When the user selects the Select Entries button 

converted digital representation is used by the GO Service 712, the system reads the Name File on the server having an 

42 as input, as a substitute for input from the keyboard or 55 IP address matching the D? address of the user's current 

mouse. Thus, a user can view the user interface display 1000 domain. The system parses the Name File and displays a list 

and speak words into the microphone to command the GO of all the real names in a new Web page that is sent to the 

Service 42 to locate a particular network resource. In this client 70. The Web page displays a radio button adjacent to 

way, the uscr can navigate the Wcb using spoken words. each of the real names in the list. By clicking on the radio 

Another alternate embodiment is shown in FIG. 9. A 60 button and then submitting the Wcb page to the system, the 

Service is implemented in the form of a Web server or system will provide statistical information for all the 

middle-tier Web application server 60a. The Web applies- selected real names in all reports that are generated later, 

tion server 60a communicates to the client 70 using HTTP The Select Time button 714 is used to identify a time 

messages through the Internet 50. The Web application frame for which statistics are to be generated. When the user 

server 60a includes a Common Gateway Interface (CGI) 65 selects the Select Time button 714, the system generates a 

script processor, an application server such as Netscape's new Web page and sends it to the client 70. The Web page 

Kiva, Microsoft's Active Server, or Apple's WebObjects®. includes a form into which the user enters a starting date and 



6,151,624 

27 28 

an ending date. When the user submits the filled-in page to may be implemented. Computer system 800 includes a bus 

the system, the system receives and stores the date values. 802 or other communication mechanism for communicating 

When reports are generated thereafter, the reports will information, and a processor 804 coupled with bus 802 for 

contain statistical information for resolutions of real names processing information. Computer system 800 also includes 

that occurred within the specified dates. 5 a main memory 806, such as a random access memory 

The Report per Entry button 716 is used to generate a (RAM) or other dynamic storage device, coupled to bus 802 

report and graph showing all real name resolutions that have for storing information and instructions to be executed by 

occurred for each real name entry defined in the current processor 804. Main memory 806 also may be used for 

Name File. When the Report per Entry button 716 is ^""S temporary variables or other intermediate informa- 

selected, the system reads statistical information that is 10 tion ^nng execution of instructions to be executed by 

stored in the statistical tables of the database 12 for each of P r ° cessor 804 £™ffi te I2 rston T ^ T J* 

. ... . c . . . XT P , t- only memory (ROM) 808 or other static storage device 

the real names that are defined in the current Name File. The „ , . . . J Z M F / . . , • ._ 

. , , , ... coupled to bus 802 for storing static information and instruc- 

system generates a graph and a chart of the statistical ^ for processor 804 . a storage device 810, such as a 

information, and generates a Web page containing the graph magDetic disk or opUc al disk, is provided and coupled to bus 

111111 cnart - 15 802 for storing information and instructions. 

FIG. 7A is an example of a Web page generated in this Computer system 800 may be coupled via bus 802 to a 

manner. The graph pane 708 shows an exemplary bar graph. display 812, such as a cathode ray tube (CRT), for displaying 

Each bar in the bar graph represents a real name defined in information to a computer user. An input device 814, inchid- 

the current Name File. The vertical axis 720 identifies the ing alphanumeric and other keys, is coupled to bus 802 for 

number (in thousands) of resolutions of each real name. The 20 communicating information and command selections to 

horizontal axis 722 identifies each name for which statistics processor 804. Another type of user input device is cursor 

information is reported. The statistics pane 710 comprises a control 816, such as a mouse, a trackball, or cursor direction 

real name column 730, a quantity of resolutions column 732, keys for communicating direction information and com- 

and a percentage column 734. The real name column 730 mand selections to processor 804 and for controlling cursor 

lists each real name that is defined in the current Name File. 25 movement on display 812. This input device typically has 

The quantity of resolutions column 732 gives the number of ^ degrees of freedom in two axes, a first axis (e.g., x) and 

resolutions of that real name that have occurred within the a sccond ^ ( e -S*' ?)» that aUows me devicc 10 specify 

currently defined lime period. The percentage column 734 positions in a plane. 

indicates, for each real name, the percentage of total reso- T 06 invention is related to the use of computer system 800 

lutions represented by the resolutions of that real name. 30 for providing a language-independent network resource 

nG.TBisanexampleofanothertypeofgraphgenerated namm e system. ,Accordmg to one embodiment of the 

by the statistics service. The vertical axis 720 shows the mventioManguage-mdependent network resource naming 

numberof resolutionsof each real name. The horizontal axis ^ Provided by computer system 800 in response to processor 

, ... r , _, 0 . . 804 executing one or more sequences of one or more 

722 comprises a plurality of bars 738, each bar associated . "... OA , _ , . 

... , ™ , , . , . « instructions contained in mam memory 806. Such instruc- 

with a real name. Ice bar represents the number of reso hi- ■» . , , . J , . 

,■ , ( . , , A _ , ... . ... tions may be read into mam memory 806 from another 

lions of that real name. A second vertical axis 736 displays ... ,. , . 

t . . r 4 .i i*- computer-readable medium, such as storage device 810. 

a number indicating the percentage 01 total resolutions „ . * . - . . . 

carried out by the system that is represented by each real Executionof the sequences of instructions contamed in mam 

, . / - . . . JL- memory 806 causes processor 804 to perform the process 

name shown m the horizontal axis 722. _ * _ , . . , , , , 

. . ,. - . . . . . , , « steps described herein. In alternative embodiments, hard- 

In an embodiment, a fee is charged by the owner of the « ^ ^ ^ ^ m placc of or m combination 

real name system to end users or customers who register real ... «. - . - . • . . ■ . „ 

• L n • , „ „ , .. _ _ j . with software instructions to implement the invention. Thus, 

names m the Registry 10. The Librarian 20 records a charge cmbodinicnLs of ^ bvcntioD ^ ^ liraited to ^ 

against the account of the user when a new entry is submit- ^^uon of hardware circuitry and software, 

ted to the system using the Registration Service 22. In ^ „ , , , , , 

another embodiment, end users oTcustomers who register «« The term computer-readable medium as used herem 

real names in the Registry 10 pay a fee to the owner of the rcfers 10 ^ medium that participates m providing mstruc- 

real name system for each resolution executed by the *?* to Processor 804 for execution Such a medium may 

Resolver 40 in response to a third-party request. The ^ ."^ ^ ""^ding but not to, non-vo atde 

Resotver 40 records a charge against the accountof the user med ^ VO a ^ e and transmission media. Non-volatde 

when each resolution is completed. In these embodiments, » media mclu ^ for ;°P Ucal ° r ^agneuc disks, such 

the account informaUon and charges are logged and accu- 35 ^ C 810 Vfo,atilc ^1 ,ndudcs 

mulated in tables of the database 12. PerioSlly, an exter- memo /* SUcfa f 5 main memory 806. Transm^sion media 

nal billing application reads the charge and account tables of mcludeS ™™ 1 co Pf er !^ J^ d fiber mclud " 

the database 12 and generates invoices that are sent to the ^ the wuj* that compose bus 802. Transmission media can 

user. The Statistics & Bfl ling/Billing Information option of * aLso fonn of acoustic or light waves such as those 

the top-level option list 702 enables the user track and £ eneraled dunng rad, °' wave and ^ ^mum- 

monitor, in real time, the user's credits and payments for cations. 

registered real name entries, as well as resolution fees. When Common forms of computer-readable media include, for 

the Billing Information function isselected, the system reads cample, a floppy disk, a flexible disk, hard disk, magnetic 

the charge and account tables of the database 12 and 60 tape, or any other magnetic medium, a CD-ROM, any other 

generates a report, in a Web page, summarizing the charges 0 P Ucal medium, punchcards, papertape, any other physical 

to the customer. The Web page is delivered to the client 70 pa " e ™ ° f J?? leS * a I ^ AM * 8 PR0M * and 

and displayed by it. EPROM, a FLASH-EPROM, any other memory chip or 

cartridge, a carrier wave as described hereinafter, or any 

Hardware Overview 65 other medium from which a computer can read. 

FIG. 8 is a block diagram that illustrates a computer Various forms of computer readable media may be 

system 800 upon which an embodiment of the invention involved in carrying one or more sequences of one or more 
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instructions to processor 804 for execution. For example, the 
instructions may initially be carried on a magnetic disk of a 
remote computer. The remote computer can load the instruc- 
tions into its dynamic memory and send the instructions over 
a telephone line using a modem. A modem local to computer 5 
system 800 can receive the data on the telephone line and 
use an infra-red transmitter to convert the data to an infra-red 
signal. An infra-red detector coupled to bus 802 can receive 
the data carried in the infra-red signal and place the data on 
bus 802. Bus 802 carries the data to main memory 806, from 10 
which processor 804 retrieves and executes the instructions. 
The instructions received by main memory 806 may option- 
ally be stored on storage device 810 either before or after 
execution by processor 804. 

Computer system 800 also includes a communication 15 
interface 818 coupled to bus 802. Communication interface 
818 provides a two-way data communication coupling to a 
network link 820 that is connected to a local network 822. 
For example, communication interface 818 may be an 
integrated services digital network (ISDN) card or a modem 20 
to provide a data communication connection to a corre- 
sponding type of telephone line. As another example, com- 
munication interface 818 may be a local area network 
(LAN) card to provide a data communication connection to 
a compatible LAN. Wireless links may also be implemented. 25 
In any such implementation, communication interface 818 
sends and receives electrical, electromagnetic or optical 
signals that carry digital data streams representing various 
types of information. 

Network link 820 typically provides data communication 30 
through one or more networks to other data devices. For 
example, network link 820 may provide a connection 
through local network 822 to a host computer 824 or to data 
equipment operated by an Internet Service Provider (ISP) 
826. ISP 826 in turn provides data communication services 35 
through the world wide packet data communication network 
now commonly referred to as the "Internet" 828. Local 
network 822 and Internet 828 both use electrical, electro- 
magnetic or optical signals that carry digital data streams. 
The signals through the various networks and the signals on 40 
network link 820 and through communication interface 818, 
which carry the digital data to and from computer system 
800, are exemplary forms of carrier waves transporting the 
information. 

Computer system 800 can send messages and receive 45 
data, including program code, through the nctwork(s), net- 
work link 820 and communication interface 818. In the 
Internet example, a server 830 might transmit a requested 
code for an application program through Internet 828, ISP 
826, local network 822 and communication interface 818. In SO 
accordance with the invention, one such downloaded appli- 
cation provides for a language-independent network 
resource naming system as described herein. 

The received code may be executed by processor 804 as 
it is received, and/or stored in storage device 810, or other 55 
non-volatile storage for later execution. In this manner, 
computer system 800 may obtain application code in the 
form of a carrier wave. 

Variations; Advantages 

In the foregoing specification, the invention has been 
described with reference to specific embodiments thereof. It 
will, however, be evident that various modifications and 
changes may be made thereto without departing from the 
broader spirit and scope of the invention. The specification 
and drawings are, accordingly, to be regarded in an illus- 
trative rather than a restrictive sense. 
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We claim: 

1. A method of locating a resource that is stored in a 
location in a network that is identified by a location 
identifier, comprising the steps of: 

storing, in a metadata registry in a first storage device, 
metadata that describes the resource in association with 
the location identifier of the resource; 

receiving a request to locate the resource, the request 
containing an element of the metadata; 

retrieving the location identifier associated with the 
resource from the metadata registry based on the ele- 
ment; 

retrieving the resource over the network using the location 
identifier, 

storing a natural language name for the resource in the 
metadata; 

receiving a request to locate the resource based on the 
natural language name; 

retrieving the location identifier associated with the natu- 
ral language name from the metadata registry using the 
natural language name; 

storing the natural language name in association with the 
location identifier in a name file in a second storage 
device associated with the resource; 

retrieving the name file; 

parsing the name file; 

building an index entry based on the values parsed from 
the name file and storing the index entry in an index of 
the metadata registry by: 

establishing, in a memory, a first index, a second index, 
a first queue associated with the first index, and a 
second queue associated with the second index; 

receiving a request to build an index entry based on the 
values parsed from the name file; 

selecting the first queue and storing the request in the 
first queue; 

when the first queue is sufficiently full, storing the 
contents of the first queue in the first index, and 
concurrently selecting the second queue and storing 
a subsequent request to build an index entry in the 
second queue. 

2. A method of locating a resource that is stored in a 
location in a network that is identified by a location 
identifier, comprising the steps of: 

storing, in a metadata registry in a first storage device, 
metadata that describes the resource in association with 
the location identifier of the resource; 

receiving a request to locate the resource, the request 
containing an clement of the metadata; 

retrieving the location identifier associated with the 
resource from the metadata registry based on the ele- 
ment; 

retrieving the resource over the network using the location 
identifier; 

storing a natural language name for the resource in the 
metadata in association with the location identifier in a 
name file in a second storage device associated with the 
resource; 

receiving a request to locate the resource based on the 
natural language name; 

retrieving the location identifier associated with the natu- 
ral language name from the metadata registry using the 
natural language name; 

retrieving the name file, parsing the name file; building an 
index entry based on the values parsed from the name 
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file; and storing the index entry in an index of the 
metadata registry; 

establishing, in a memory, a first index, a second index, a 
first queue associated with the first index, and a second 
queue associated with the second index; 5 

receiving a request to build an index entry based on the 
values parsed from the name file; selecting the first 
queue and storing the request in the first queue, and 
when the first queue is sufficiently full, storing the 
contents of the first queue in the first index, and 10 
concurrently selecting the second queue and storing a 
subsequent request to build an index entry in the second 
queue; 

alternately selecting the first queue and the second queue 15 
in response to successive requests to build an index 
entry. 

3. A method of locating a resource that is stored in a 
location in a network that is identified by a location 
identifier, comprising the steps of: ^ 
storing, in a metadata registry, metadata that describes the 
resource in association with the location identifier of 
the resource, by the steps of: receiving a client identifier 
of a client associated with the resource; generating 
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values for the metadata that describe the resource, the 
location identifier, and the client identifier; and storing 
metadata in a persistent storage device associated with 
the client; 

receiving a request to locate the resource, the request 
containing an element of the metadata; 

retrieving the location identifier associated with the 
resource from the metadata registry based on the ele- 
ment; 

retrieving the resource over the network using the location 
identifier; 

instructing the client to store the metadata in a particular 
authorized location in the persistent storage device; 

building an index entry based on the values parsed from 
the name file; and storing the index entry in an index of 
the metadata registry by establishing, in a memory, a 
first index, a second index, a first queue associated with 
the first index, and a second queue associated with the 
second index by establishing the first queue in a first 
server and establishing the second queue in a second 
server that is separate from the first server. 



